Ed Note:
This is a very important, and simple, optimization that can have a huge effect on our MOOs. I have done this on my test moo and it makes an amazing change. The larger the database the bigger the improvement! It effects any verb which calls suspend(). Alexandre's post below explains how this works.

Note as of September 2006 the default settings in a base enCore v4 core still need this fix!

Ciao
KJ
==========================================

From: encore-bounce@utdallas.edu on behalf of Alexandre Borgia
Sent: August 8, 2002 3:42 AM
To: encore@utdallas.edu
Subject: [encore] how to speed up an enCore DB ...

Follow Up Flag: For Your Information
Flag Status: Flagged

Greetings,

	I don't remember this issue being discussed before, pardon me if so:)

	It all started when I found strange that a verb compiled within a virgin 
"latest-release" LambdaDB took aprox. 4 minutes to finalize his tasks, while 
running it from a virgin "latest-release" enCoreDB took - *glup* - about 2 
hours!  The 2 DBs were using the same LambdaMOO server, on the same machine.

	The problem was that I used "$command_utils:suspend_if_needed".  In both DBs, 
it has (almost) the same code/behavior, that is, to check if a verb is 
running out-of-ticks, and if so it calls the "suspend" command to get some 
more running time.  It also has a (neat?) feature that checks the MOO lag and 
won't allow you to suspend for less than the lag-value.

	The lag-value is generated by "$login:sample_lag", and then stored in 
"$login.current_lag".  The thing is, this verb is not run automatically, and 
there is probably a lot of MOOs not even aware of this feature.  So, 
considering you haven't started the process, the current lag value will 
remain the same forever.

	In LambdaDB, this value is set to 0 by default.  In enCore, it is set to 6!  
So everytime "$command_utils:suspend_if_needed" is called, even if you pass 0 
as argument, it will *always* wait at least 6 seconds before resuming.

	Was this intended?

	Although a lot of "core" verbs use "suspend_if_needed", most of the basic 
procedures (like telling something, droping an object, looking at a room, 
etc.) are quite easily computed and won't show up much performance drop.  But 
if you have some management/research/etc. algorithms that loops a lot, 
setting "$login.current_lag" to 0 will without doubts speed things up 
tremendiously:)  This goes for a lot of MOO background commands ... 
$room_db:update(), for example, used to a minute, now it takes less than a 
second.  This also explains strange behaviors I had, like having to wait 
periodically during looking, editor-listing, "@audits", etc.


	Another similar behavior:
		In LambdaDB: "$list_utils:iassoc_suspended" suspends to 0 by default.
		In enCoreDB: the same verb suspends at 1 by default.  Worst, it calls 
"$command_utils:suspend_if_needed" ... so it really suspends at 6 ;)

	I suspect a lot of other commands to be "slowed down" like this; these are 
the two I used with what I'm testing and I have not searched for others yet.

	I haven't really followed DB developments from either enCore or Lambda, nor 
know if/when enCore stopped using Lambda releases ... I don't know when these 
changes were included, and by whom.

	This "lag-system" is probably a great tool for huge MOOs, but considering the 
size of most of them I don't think its really neccessary.  A way to identify 
"normal/user" use from "time-critical/wizardly" use would at least be great 
to implement.

	And again, maybe you're all already aware of this:)

	- Alexandre Borgia

====================================
From: encore-bounce@utdallas.edu on behalf of George Hager
Sent: August 9, 2002 8:24 AM
To: encore@utdallas.edu
Subject: [encore] Re: how to speed up an enCore DB ...

>	The lag-value is generated by "$login:sample_lag", and then stored in 
>"$login.current_lag".  The thing is, this verb is not run 
>automatically, and there is probably a lot of MOOs not even aware of 
>this feature.  So, considering you haven't started the process, the 
>current lag value will remain the same forever.

Thanks for sharing this! I have been battling a timing problem for 
months. My MOO generates whole zones of rooms on-the-fly, but there 
was some lag time while the MOO rebuilt exit connections for the new 
rooms. The only solution was to lock players in the entry room for a 
frustrating period while forked tasks customized the new zone.

Last night I tried running $login:sample_lag(), but the variable 
suspension time  meant that the forked tasks were hardly ever in 
sync, even when I set the maximum $login.current_lag at 2.

I just set the $login.current_lag to 0 like you suggested, disabled 
$login:sample_lag() completely, and now everything is faster *and* 
more consistent, and players aren't held up waiting while new rooms 
are being built.

==========================================
From: encore-bounce@utdallas.edu on behalf of Jan Rune Holmevik
Sent: August 19, 2002 11:57 AM
To: enCore list
Subject: [encore] Re: how to speed up an enCore DB ...

Thanks to Alexandre for finding this issue. When we started enCore in 97 we used 
the then current version of LambdaCore, and the lag value you mention must be 
inherited from that Lambda release. To fix this, it is recommended that all enCore 
MOO admins with small to medium sized MOOs set the value of $login.current_lag to 0.

Cheers,
Jan